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program content or functionality has been changed. 



(57) Abstract: The invention basically 
relates to the following: in a first variant, 
selected components of a software are used 
as variation points, wherein said components 
are transformed into a first XML code. The 
software, which is now in mixed form, is 
delivered. On the user side, the first code is 
converted into a second XML code depending 
only upon transformation rules by means of 
one or more transformations, e.g. XSLT In 
a second variant, a first XML code, which 
contains at least one language extension, is 
converted into a second, more easily verifiable 
XML code without said language extensions 
depending on transformation rules. In a third 
variant, a source code formulated in XML is 
transformed in such a way that a new source 
code is obtained after back-conversion into the 
original programming language, in which not 
only the presentation but also the actual program 
content or functionality has been changed. In 
a fourth variant, a source code formulated in 
XML, for instance, with initial states, code 
fragments to be exchanged and foreign language 
modules tailored to the corresponding natural 
language of the user, are mixed by means of 
transformation, whereby a new source code 
is obtained after back-conversion, in which 
not only the presentation but also the actual 

[Fortsetzung auf der ndchsten Seite] 
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Veroflentlicht: 

ohne intemationalen Recherchenbericht und erneut zu ver- 
offentlichen nach Erhalt des Berichts 

Zur Erklarung der Zweibuchstaben- Codes und der anderen Ab- 
kurzungen wird auf die Erkldrungen ("Guidance Notes on Co- 
des and Abbreviations ") am Anfangjeder regularen Ausgabe der 
PCT-Gazette verwiesen. 



(57) Zusaimnenfassung: Die Erfindung besteht im Wesentlichen darin, dass in einer ersten Variante ausgewahlte Bestandteile ei- 
,n S hT 6 Van , atl ° nS P un ^ e dienen - indem diese ^ einen in einen ersten XML-Code umgewandelt werden, die Software nun 
.n Mischform, ausgehefert wu-d, und der erste Code kundenseitig durch eine oder mehrere Transformationen, bspw. XSLT, nur in 

2n ,S SrT aQ r Sregeln ^ eine " in Cinen ZWeiten XML " C ° de «mgewandelt werden, dass in einer zweiten Variante 

ein erster XML-Code, der rtundestens eine Spracherweiterung enthalt in Abhangigkeit von Transformationsrcgeln in einen leich- 
ter venfizierbaren zweiten XML-Code ohne diese Spracherweiterungen uberfuhrt wird, dass in einer dritten Variante ein in XML 

™o n Q h ? ^ST- f^ 01 ™ 6 * WM ' daSS ' nach einer R^kkonvertierung in die ursprungliche Programmiersprache, ein 
neuer Quellcode entsteht, be, dem nicht nur die Darstellung, sondern aueh der eigentliche Progmmminhalt bzw. die Funktiomditat 

~T T r °h R ,n emer T*" Variante ei " in ^ formulierter Q^Hcode mit beispielsweise Ausgangszustanden, aus- 
zutauschenden Code-Fragmenten und auf die jeweilige natiirliche Sprache des Anwenders zugesehnittenen Fremdsprachenmodulen 
durch Transformation vernuseht wird, woduich, nach einer RUckkonvertierung ein neuer Quellcode entsteht, bei dem nicht nur die 
Darstellung, sondern auch der eigentliche Programminhalt bzw. die Funktionalitat verandert wunde 
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Beschreibung 

Verfahren und Anordnung zur Veranderung von Software Oder 
Quellcode 

Die Erfindung betrifft ein Verfahren und eine Anordnung zur 
Veranderung von Software oder Quellcode, bei dem/der eine 
Software bzw. ein Quellcode, in eine Darstellung in einer 
Meta-Auszeichnungssprache, beispielsweise XML, ubergefuhrt, 
dort, beispielsweise mit XSLT, trans formiert und dann diese 
in der Meta-Auszeichnungssprache formulierte transformierte 
Darstellung in eine modif izierte Software oder in einen 
modifizierten Quellcode, beispielsweise derselben 
Ausgangssprache, zuriickverwandelt wird. 

Aus dem Stand der Technik sind zwar einige MSglichkeiten zur 
nachtraglichen Veranderung bzw. Modif ikationen von Software 
bekannt, die jedoch alle einige Nachteile gegentiber der 
Erfindung aufweisen: 

* 

Eine M6glichkeit der Einf lussnahme auf Software erfolgt mit 
Hilfe einer Parametrisierung. Konf igurationsdateien werden 
typischerweise zur Parametrisierung und Speicherung 
anwendungsspezifischer „Parameterdaten* verwendet. Die 
Struktur und der Aufbau dieser Dateien wird dabei 'wahrend der 
Entwicklungsphase festgelegt, und ist in keinem Fall nach der 
Auslieferung der Software veranderbar. 

Pluglns erSffnen die MOglichkeit schon „ausgelief erte* , 
kompilierte Software urn Funktionalitatseigenschaf ten zu 
erweitern. Hierfur ist es notwendig, dass die Strukturen zur 
Einbindung und Nutzung von Pluglns bereits wahrend der 
Entwicklungsphase erstellt bzw. festgelegt werden ■ 
(Schnittstellen, . . . ) . 

» ■ 

Code-Generatoren erzeugen Quell- oder BinarCode mit Hilfe von 
Templates/Vorlagen, die an vorgegebenen Stellen, z. B. 
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mittels tibergebener Parameter, vervollstandigt werden. Auf 
diese Weise wird es mdglich, dass z. b. ftir verschiede Kunden 
unterschiedliche Software erzeugt wird, die sich an genau 
definierten Stellen unterscheidet . Hierbei sind aber nur 
spezielle Stellen (und nicht beliebige Stellen) im Code 
veranderbar, welche mit der Erstellung des Templates genau 
spezifiziert werden mttssen. Code-Generatoren werden typischer 
Weise auf Entwicklerseite eingesetzt. 

US-Patentanmeldung US 6052531A1 ist eine spezielle 
Anwendungsmdglichkeit von Variationspunkten in Form von 
Updates/Patches bekannt. 

Aus dem Internet ist unter http : //beautyj .berlios .<w e in 
Java Source Code Transformation Tool Beautyj bekannt, bei dem 
em Java Quellcode in eine XML-Darstellung umgewandelt wird, 
mittels Sourclet API, beispielsweise durch Einftigen von 
Leerzeichen Oder geanderten Kommentaren an bestimmten 
Stellen, „verschonert* und anschliefiend der modifizierte 
Quellcode in Java Quellcode zurtick konvertiert werden kann. 
Eine Transformation mittels XSLT wird hier, ftir diesen Zweck, 
nur vorgeschlagen, aber nicht umgesetzt. 

Die der Erfindung zugrunde liegende Aufgabe liegt nun darin, 
ein Verfahren und eine Anordnung zur Modifikation von 
Quellcode anzugeben, bei dem/der eine weitergehende noch 
flexiblere und effizientere Modifikation der Software bzw. 
des Quellcodes erreicht wird. 

Diese Aufgabe wird hinsichtlich des Verfahrens durch die 
Merkmale der Patentansprtiche 1, 6, 8 und 13 und hinsichtlich 
der Anordnung durch die Merkmale der Patentansprtiche 22 bis 
2 6 erfindungsgemaii gelost. Die weiteren Ansprtiche betreffen 
bevorzugte Ausgestaltungen der Erfindung. 



Die Erfindung besteht im Wesentlichen dar 



xn, 



2 



WO 2004/088549 



PCT/EP2004/003301 



10 



15 



20 



25 



30 



35 



dass in einer ersten Variante ausgewahlte Bestandteile einer 
Software als Variationspunkte dienen, indem diese in einen 
in einer Meta-Auszeichnungssprache, bspw. XLML, f ormulierten 
ersten Code umgewandelt werden, die Software nun in 
Mischform, ausgeliefert wird, und der erste Code kundenseitig 
durch eine oder mehrere Trans format ionen, bspw. XSLT, nur in 
Abhangigkeit von Trans format ionsregeln in einen in der Meta- 

Auszeichnungssprache formulierten zweiten Code umgewandelt 
werden, 

dass in einer zweiten Variante ein in einer Meta- 
Auszeichnungssprache formulierter erster Code, der mindestens 
eine Spracherweiterung enthalt in Abhangigkeit von 
Transformationsregeln in einen in der Meta- 
Auszeichnungssprache formulierten leichter verif izierbaren 
zweiten Code ohne diese Spracherweiterungen uberftihrt wird, 
dass in einer dritten Variante ein in eine Meta- 
Auszeichnungssprache transformierter Quellcode derart 
transformiert wird, dass, nach einer Rtlckkonvertierung in die 
ursprtingliche Programmiersprache, ein neuer Quellcode 
entsteht, bei dem nicht nur die Darstellung, sondern auch der 
eigentliche Programminhalt bzw. die Funktionalitat verandert 
wurde, oder 

dass in einer vierten Variante ein in eine Meta- 
Auszeichnungssprache transformierter Quellcode mit 
beispielsweise Aus gangs zustanden, auszutauschenden Code- 
Fragmenten und auf die jeweilige naturliche Sprache des 
Anwenders zugeschnittenen Fremdsprachenmodulen durch 
Transformation vermischt wird, wodurch, nach einer 
Rtlckkonvertierung ein neuer Quellcode entsteht, bei dem nicht 
nur die Darstellung, sondern auch der eigentliche 
Programminhalt bzw. die Funktionalitat verandert wurde. 



Die Erfindung wird im Folgenden anhand der in den Zeichnungen 
dargestellten Beispiele naher erlautert. Dabei zeigt 
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Figur 1 ein Gesamtblockdiagramm zur Erlauterung einer 

ersten Erf indungsvariante, 

Figur 2 ein Gesamtblockdiagramm zur Erlauterung einer 
5 zweiten Erf indungsvariante, 

Figur 3 ein Blockschaltbild zur Erlauterung der 

erfindungsgemafien OberfUhrung von Preprocessing- 
Erweiterungen, 
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Figur 4 ein Gesamtblockdiagramm zur Erlauterung einer 

dritten Erf indungsvariante, 

Figur 5 ein Blockschaltbild zur Erlauterung der 

erfindungsgemalien Modifikation durch die Verwendung 
von Aspekten, 



Figur 6 ein Blockschaltbild zur Erlauterung des 

erfindungsgemaiien Einftigens von Migrierbarkeits- 
20 Funktionalitat, 

Figur 7 ein Blockschaltbild zur Erlauterung der 

erfindungsgemaiien Modifikation durch den Einsatz 
von Templates, Filtern und Patterns, 



Figur 8 Gesamtblockdiagramm zur Erlauterung einer vierten 

Erf indungsvariante, 

Figur 9 ein Blockschaltbild zur Erlauterung des 

erfindungsgemafien Austauschens von Code-Fragmenten, 

Figur 10 ein Blockschaltbild zur Erlauterung des 

erfindungsgemaflen Einftigens von Zustandsdaten, 

Figur 11 ein Blockschaltbild zur Erlauterung der 

Variationsmoglichkeiten des erfindungsgemaiien 
Einbaus von Informationen und 
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Figur 12 ein Blockschaltbild zur Erlauterung des 

erfindungsgemafien Einbaus von Fremdsprachmodulen 
zur Internationalisierung des Quellcodes 

5 

1 . Erf indungsvariante 

In Figur 1 1st ein Gesamtblockdiagramm zur Erlauterung der 
Erfindung dargestellt, bei dem zunachst eine Software SW 
10 bestehend aus Quelltext SCI, SC2 und SC in eine 

auslieferungsfahige Software SW* umgewandelt wird, wobei 
einige Telle der Software wie bspw. SCI nun als 
Binarcode/Byte Code Bl zur Verftigung stehen, und andere Telle 
wie bspw. SC2 durch einen Konverter CONV in einen in einer 
15 Meta-Auszeichnungssprache formulierten ersten Code CodeML 
umgewandelt werden, so da* sie in der lauffahigen Software 
SW* fortan Variationspunkte VP bspw. VP1 bilden. Diese 
Software SW* kann vor/oder zur Laufzeit auf eine Weise 
modifiziert werden, das der in der Meta-Auszeichnungssprache 
dargestellte Code VP, bspw. VP2 , mit einer Transformation T 
und Trans formationsregeln TR in einen zweiten in der Meta- 
Auszeichnungssprache formulierten Code CodeML* umgewandelt 
wird, welcher nun entweder als geanderter Variationspunkt 
bspw. VP2* in SW* vorhanden ist Oder durch einen Konverter 
25 RCONV nach der Transformation T in einen Quellcode SC* und 
danach mittels COMP in einen ByteCode/Binarcode VP2B* 
uberfuhrt wird. In beiden Fallen unterscheiden sich SW und 
SW* an den Stellen der Variationspunkte und konnen auf diese 
Weise an spezifische Anforderungen (bspw. Tookit-Austausch, 
Updates, usw. ) angepasst werden. 



20 



30 



35 



Die Codes CodeML und CodeML* bzw. VP und VP* sind 
beispielsweise in der Meta-Auszeichnungssprache XML 
formuliert, wobei „XML« fur Extended Markup Language steht 

Von besonderem Vorteil ist hierbei, dass dies nicht vom 
Programmentwickler durchgeftihrt werden muss, sondern vom 
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entsprechend ausgestatteten und informierten Kunden selbst 
erledigt werden kann. Hierzu braucht ein Operator oder 
Administrator auf der Kundenseite nur eine entsprechende 
Transformation T mit den benOtigten Ersetzungs-, 
Modi fikat ions- und Entfernungsregeln TR anzuwenden, urn die 
Software auf seine speziellen Bedtlrfnisse anzupassen bzw. ein 
Update oder Patching durchzuf tihren . Beim Update oder Patching 
von kundenspezifisch angepasster treten bislang haufig 
Probleme wegen Inkonsistenzen auf, die durch diese Erfindung 
und die Moglichkeit der Pipelineanwendung bzw. geordnete 
HintereinanderausfUhrung von Anfang an vermieden werden 
konnen . 
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Die im Anhang 1 befindlichen Programmauf listungen Listing 1 
bis Listing 5 zeigen dies an einem konkreten Beispiel: 
Typischerweise kann eine Sof tware-Auslieferung an zwei 
unterschiedliche Kunden unterschiedliche Toolkits verwenden, 
die sich hinsichtlich Performance, Preis usw. unterscheiden! 



So soil hier ein Code der ursprtinglich eine 
Regis trierungsklasse 
import electric. registry. Registry 

aus einem Glue-Toolkit verwendet, beim zweiten Kunden nun 
zwei neue "Registrierungsklassen" 
25 import org. apache. axis. client. Call und 

import org. apache. axis. client. Service aus einem Axis- 
verwenden . 



In XSL kann dies z.B. mittels 



<xsl:template match="import"> 

<xsl : i f test="dot/name= • Registry '"> 
<import> 
<dot> 



<dot><dot><dot><name>org</name><name>apache</name></dot><name>axi 
<name>oHent</name></dot><narae>Call</nam e > name>axi. 



</dot> 

. _ </import> 
4 5 </xsl:if> 



s</name></dot> 

</dot> 
</import> 
<import> 
<dot> 

<name>client</name></dot><name>Servlce</name> /namex/aow 
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<xsl : if test= M dot/name ! = ■ Registry » "> 

<xsl:copy-of select= n . "/> 
</xsl:if> 



</xsl : template> 



geschehen. Schablonen bzw. Templates werden in XSL auf das in 
match definierte Muster angewendet. Das import-Template im 
Listing-Beispiel also auf alle ursprunglichen import- 
Anweisungen. Im konkreten Beispiel ignoriert es einfach alle 
ursprunglichen GIUE-Registry- Imports, und fUgt stattdessen 
die zwei Axis-spezif ischen imports ein. 

Durch das erf indungsgemafle Verfahren ergeben sich noch eine 
15 Reihe von zusatzlichen Vorteilen, wie beispielsweise: 

1. Es ist nur ein System fur Problemstellungen wie Patching, 
Customizing, Updating, etc. erforderlich und nicht eine Reihe 
verschiedener teilweise proprietarer Werkzeuge. 



2. Das Verfahren basiert auf Standards wie XML und XSLT und 
ist hinsichtlich der Konvertierbarkeit in andere 
Programmiersprachen geringeren Beschrankungen unterworfen als 
andere Verfahren zur Modifikation von Quellcode. 

3. Selbst fur spezielle und komplizierte Quellcode- 
Modifikationen sind keine proprietaren Speziallosungen 
erforderlich, sondern es kSnnen hierfUr existierende 
Standards wie XSLT, XPath und XQuery genutzt werden. 

4. Diese Art der Modifikation erlaubt die Erstellung von 
Hierarchien u.a. durch die Moglichkeit zur geordneten, 
automatisierten Hintereinanderausfiihrung (Pipelines) mehrerer 
Transformationen, bspw. von Patches. 

5. Die Transformationen konnen fur eine allgemeine 
Wiederverwendung in XSLT-Dateien gespeichert werden, so dafi 
Bibliotheken z.B. fur bestimmte Ablaufe entstehen konnen. 
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6. Es kann eine XML-Reprasentation des Quellcodes in einer 
XML-Da tenbas is gespeichert und bei Bedarf mit Hilfe einer 
XSLT in einfacher Weise an die jeweiligen Kundenbedtirfnisse 
angepasst werden (Customization) . 

7. Durch die Verwendung der Standards XMLSchema oder DTD oder 

entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , 

auf bestimmte Korrektheitsaspekte hin, uberprtift (validiert) 
werden. 

8. ubliche XML-Tools kdnnen zur einfachen Bearbeitung bzw. 
Visualisierung und Bestimmung von Beziehungen im Code 
verwendet werden. 

9. Dauerhafte XML-basierte Programmbibliotheken, die XPath- 
Anfragen unterstutzen, kdnnen die Wiederverwendung von Code 
durch besseres Auffinden eines Codes bzw. von Code-Fragmenten 
oder Templates verbessert werden. 



2 . Erf indunqsvariante 

In Pigur 2 ist ein Gesamtblockdiagramm zur Erlauterung der 
Erfindung dargestellt, bei dem ein in einer Meta- 
Auszeichnungsprache formulierter erster Code CodeML, der eine 
Spracherweiterung LE enthalt und durch RCONV nicht in 
gUltigen Quelltext SC* uberfuhrbar ist, durch eine 
Transformation T in Abhangigkeit von Transformationsregeln 
TR, welche einen Sprachkonverter LC enthalten, in einen in 
der Meta-Auszeichnungssprache formulierten zweiter Code 
CodeML* ohne uberftihrt wird, welcher keine diese 
Spracherweiterungen LE enthalt und deshalb in einen Quellcode 
SC* verwandelt werden kann, welcher mittels eines Compilers 

COMP wiederum in gtiltigen Binarcode/ByteCode B* uberfuhrbar 
ist . 
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Der modifizierte Quellcode SC* sind beispielsweise in der 
Programmiersprache Java und die Codes CodeML und CodeML* sind 
beispielsweise in der Meta-Auszeichnungssprache XML 
formuliert, wobei „XML* fur Extended Markup Language steht. 

Die Transformation T, z. B. eine Extended Stylesheet Language 
Transformation oder XSLT, wird durch Trans formationsregeln 
TR, z. B. innerhalb von XSL (Extended Stylesheet Language) 
Dateien beschrieben, wobei bspw. die in XSL formulierten 
Regeln u.a. als Language Converter LC verwendet werden und 
beschreiben wie der in XML-codierte Quellcode CodeML mit 
einer Spracherweiterung LE in eine Variante ohne 
Spracherweiterung transformierbar ist. 



In Figur 3 ist ein erstes Ausftlhrungsbeispiel dargestellt, 
bei dem ein in einer Meta-Auszeichnungssprache formulierter 
erster Code CodeML eine Spracherweiterung fur Preprocessing 
PPE (z.B. <define>, <ifdef>, usw.) enthalt, und mit Hilfe 
20 einer Trans formtion T in Abhangigkeit von 

Trans formationsregeln TR, welche einen Preprocessing Language 
Converter PPLC besitzen der PPE auflOst bzw. anwendet, in 
einen in der Meta-Auszeichnungssprache formulierten zweiten 
Code CodeML* ohne Spracherweiterung transf ormiert wird 

25 

Die Ausgestaltung der Spracherweiterung erfolgt 
typischerweise in Form von Elementen fur die generische 
Programmierung 1 , und/oder ftir Preprocessing 2 und/oder eine 
kunden- bzw. entwicklerspezifische Grammatik 3 und/oder ftir 
30 Makros 4 . 

Alle Spracherweiterung bzw. der CodeML selbst kann jederzeit 
durch den Einsatz von DTDs (document type definitions) bzw. 
XMLSchema validiert werden. 



Der Programmierer erhalt durch die Erfindung mehr Freiheiten, 
da die Grammatik der verwendeten Programmiersprache auf die 
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Wunsche des Programmierers abgestimmt werden kann und eine 

Riicktrans formation auf die normale Grammatik der 

Programmiersprache erst , am Ende der Programmentwicklung 

erfolgen muss. Ein wesentlicher Vorteil besteht auch darin, 

5 dass eine Validierung der Spracherweiterungen mit einem fur 

die normale Programmiersprache vorgesehenen Compiler erfolgen 
kann. 



Die im Anhang 2 befindlichen Programmauf listungen 
10 bis Listing 3 zeigen die Auflosung der PreProcessing- 

Erweiterungen PPE an einem konkreten Beispiel, bei dem die in 
Listing 1 dargestellte Klasse TestOutput .xjava eine PPE in 

Form von <define name="m" value="private"> enthalt, welche Einflufl 

auf die Werte der <m>-Elemente nimmt, und durch eine 
15 Transformation T in Abhangigkeit von Transformationsregeln TR 
(hier: PPLC) nun in die in Listing 2 dargestellte XML- 
basierte Form TestOutput. xjava* uberftihrt wird, bei der alle 
<m>-Elemente durch ein uber vaiue^'private" bestimmtes <private/>- 
Element ersetzt werden. Hiermit wird es moglich 
20 TestOutput. xjava* in den in Listing 3 aufgezeigten Quellcode 
TestOutput. java zu iiberftihren. 

Durch das erf indungsgemafie Verfahren ergibt sich noch eine 
Reihe von weiteren Vorteilen, wie beispielsweise : 



25 



30 



1. Es ist nur ein System fur Problemstellungen wie 
Customizing von Programmiersprachen, usw. erforderlich und 
nicht eine Reihe verschiedener teilweise proprietarer 
Werkzeuge . 



2. Das Verfahren basiert auf Standards wie XML und XSLT und 
ist hinsichtlich der Konvertierbarkeit in andere 
Programmiersprachen geringeren Beschrankungen unterworfen als 
andere Verfahren zur Modifikation von Quellcode. 

35 

3. Selbst fur spezielle und komplizierte Quellcode- 
Modifikationen sind keine proprietaren Speziall5sungen 
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erforderlich, sondern es konnen hierftir existierende 
Standards wie XSLT, XPath und XQuery genutzt werden. 

4. Diese Art- der Modification erlaubt die Erstellung von 
5 Hierarchien u.a. durch die M6glichkeit zur geordneten, 

automatisierten Hintereinanderausftihrung (Pipelines) mehrerer 
Transformationen, bspw. von Sprachanpassungen. 



10 



5. Die Trans format ionen konnen fur eine allgemeine 
Wiederverwendung in XSLT-Dateien gespeichert werden, so dafi 
Bibliotheken z.B. fur bestimmte Ablaufe entstehen konnen. 



15 



20 



25 



6. Es kann eine XML-Reprasentation des Quellcodes in einer 
XML-Datenbasis gespeichert und bei Bedarf mit Hilfe einer 
XSTL in einfacher Weise an die jeweiligen Kunden- bzw. 
Entwicklerbedurfnisse angepasst werden (Customization) . 

7. Durch die Verwendung der Standards XMLSchema oder DTD oder 

entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , 

auf bestimmte Korrektheitsaspekte hin, uberpraft (validiert) 
werden. 

8. Obliche XML-Tools kOnnen zur einfachen Bearbeitung bzw. 
Visualisierung und Bestimmung von Beziehungen im Code 
verwendet werden. 



30 



3 . Erf indunqsvariante 



In Figur 4 ist ein Gesamtblockdiagramm zur Erlauterung der 
Erfindung dargestellt, bei dem zunachst ein Quellcode SC 
durch einen Konverter CONV in einen in einer Meta- 
Auszeichnungssprache formulierten ersten Code CodeML 
35 umwandelt wird, wobei der Quellcode SC bei sofortiger 

Kompilierung einen Byte Code bzw. Binarcode B ergeben wtirde. 
Der in der Meta-Auszeichnungssprache dargestellte Code CodeML 
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wird nun auf dem Wege einer Transformation T ausschliefilich 
durch die Verwendung von Transformationsregeln TR 
modifiziert, welche aus Bedingungen C und/oder Logik L 
und/oder Code- Fragment en CF bestehen, wodurch sich ein 
5 zweiter ebenfalls in der Meta-Auszeichnungssprache 

formulierten Code CodeML* ergibt. Ein weiterer Konverter 
RCONV wandelt nach der Transformation den Code CodeML* in 
einen Quellcode SC* zuruck, der typischerweise in derselben 
Sprache wie der Quellcode SC formuliert ist. Durch einen 

10 Compiler COMP wird schliefilich der modifizierte Code SC* in 
einen modif izierten Byte Code B* Oder aber gleich in einen 
ausftthrbaren Binarcode umgewandelt. Wesentlich ist hierbei, 
dass sich der Byte-Code B* prinzipiell vom Byte-Code B 
unterscheidet bzw. dass der Quellcode nicht nur in seiner 

15 Darstellung, sondern auch in seinem Programmablauf geandert 
wurde. 

Der Quellcode SC und der modifizierte Quellcode SC* sind 
beispielsweise in der Programmiersprache Java und die Codes 
20 CodeML und CodeML* sind beispielsweise in der Meta- 
Auszeichnungssprache XML formuliert, wobei „XML ,k fur Extended 
Markup Language steht. 

Die Transformation T, z. B. eine Extended Stylesheet Language 
25 Transformation oder XSLT, wird durch Transformationsregeln 
TR, z. B. innerhalb von XSL (Extended Stylesheet Language) 
Dateien beschrieben, wobei bspw. die in XSL formulierten 
Regeln TR u.a. beschreiben wie der in XML-codierte Quellcode 
CodeML mit dem Code-Fragment CF kombiniert wird, urn einen 
30 neuen modif izierten Quellcode CodeML* mit integriertem CF, 
oder eine Abwandlung davon, zu bilden, welcher nun 

beispielsweise zusatzliche Logging-Funktionalitat enthalten 
kann. 

35 In Figur 5 ist ein erstes Ausf iihrungsbeispiel dargestellt, 

bei dem die Transformationsregeln TR speziell Aspektregeln AR 
nach Aspektorientierter Programmierung (AOP) entsprechen, die 
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in der Aspect J-Sprache ausgedriickt mindestens einen Pointcut 
PC und/oder mindestens einen Advice-Type AT und/oder 
mindestens ein Advice-Body AB enthalten und in ihrer 

Reihenfolge den Bestandteilen aus Figure 5 zugeordnet werden 
konnen . 



Auf diese Weise kann eine (werkzeugunabhangige) sogenannte 
AOP realisiert werden, die im Vergleich zu anderen 
Losungsvarianten, beispielsweise AspectJ, keinen zusatzlichen 
Overhead im generierten Code CodeML* erzeugt und nicht den 
Ublichen Einschrankungen (extra Kompiler, Syntax, usw.) 
existierender Aspektsprachen unterliegt. 

Als Aspekt bezeich.net man in AOP eine Einheit, die 
uberkreuzende Anliegen (crosscutting concerns) z.B. ein 
Logging, modularisiert und an einer Stelle kapselt. Der 
entsprechende Code, der bisher mehrere Module durchzog, wird 
hierbei mit Hilfe eines einzigen Aspekts zusammengefuhrt . 

Die im Anhang 3 befindlichen Programmauf listungen Listing 1 
bis Listing 5 zeigen dies an einem konkreten Beispiel, bei 
dem zunachst die in Listing 1 enthaltene Datei 
TestCalculator. java in eine XML-Darstellung 

TestCalculator.xjava konvertiert wird. In Listing 3 erfolgt 
die Beschreibung eines Aspektes in Form einer Datei 
LoggingAspect.xsl, die alle notwendigen Trans format ionsregeln 
enthalt und dafiir sorgt, dass jede Methode, die ein „cal* in 
ihrem Namen tragt, gefunden wird und zu Beginn der Ausfuhrung 
dieser Methode ein Druckbefehl System. out. prin tin („ calculate 
begin") und am Ende der Ausftihrung dieser Methode ein 
Druckbefehl System. out. println („calculate end") eingesetzt 
wird. 



Sollen z.B. in alien 151 Klassen eines Projektes, alle 
Methoden die dem Muster „cal" entsprechen, also z.B. public 
String calcValues{) o. a., dazu veranlasst werden, eine 
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System-Ausgabe beam Eintritt und Austritt zu tatigen, so 
werden zunachst mit 



match="* [ (name () =• curly ■ ) and (ancestor : : method [contains (name, 'cal' ) ] ) ] » 

alle Methoden mit dem „cal*- Muster ausgewahlt, mit 

<expr> 
<paren> 

<dot><dot><narae>System</name><name>out</name></dot><name>println</name></dot> 
<expr> 

<Sr> eXt> " </XSl:teXt><XSl:ValUe "° f select= "- ■/"a»eVXxsl:text> begin»</x S l :text> 
</exprs> 
</paren> 
</expr> 

ein Statement "System. out. prin tin (%Name der Methode% + " begin")", 
Z.B. System. out.println( "calculate end"), eingeftigt, mit 

<xsl:copy-of select="*" /> 

der ursprtinglichen Code der Methode eingeftigt und mit 



<expr> 
<paren> 

<dot><dot><name>System</name><name>out</name></dot><name>println</name></dot> 
^©xpjrs^ 

<expr> 

</exJr> eXt> " </XSl!teXt><XSl:ValUe ~ 0f select ="- • /na « ne "/><xsl:text> end»</x E l :text> 
</exprs> 
</paren> 
</expr> 

ein Statement "System, out. prin tin (%Name der Methode % + » end")", z.B 
System, out .prin tin ("calculate end") eingeftigt . 

Anstatt also in alien 151 Klassen eine entsprechende Logging 
Ausgabe zu veranlassen, kann dies hier innerhalb eines 
Logging-Aspektes an einer S telle erfolgen. Anderungen mussen 
so auch nur an einer Stelle vorgenommen werden. 



Figur 6 betrifft ein zweites Anwendungsbeispiel der 
Erfindung, bei dem ebenfalls aus einem Quellcode CodeML durch 
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15 



die Transformation T ein transformierter Code CodeML* erzeugt 
wird, welcher nun einen Mechanismus zur Sicherung (OLD) bzw. 
Ermittlung (NEW) mindestens eines Zustandes fur die 
gewtinschte (Versions) Migration enthalt. Die 
Transformationsregeln TR sind in diesem Fall derart 
ausgebildet, dass sie als Migrationsregeln MR bezeichnet 
werden konnen und neben C und L zusatzlich mind, ein 
Fragment, sogenannte Checkpoints CP, zur Generierung (CP 
Write) bzw. zum Einlesen (CP Read) von Zustanden (CP Data) 
enthalten, die eine Migration von einer alteren Version B*OLD 
auf eine neuere Version B*NEW ermoglichen. 

Die ftir eine Migration erforderliche Formatkonvertierungen 
der zu ubergebenden Systemzustande k6nnen hiermit ebenfalls 
berucksichtigt werden. Zukunftige Migrationen brauchen 
hierdurch nicht schon im Vorfeld berucksichtigt zu werden, 
wodurch der Testaufwand und diesbeztigliche potenzielle 
Programmfehler in fruhen Programmversionen vermieden werden 
Durch eine Automatisierung der Migration werden menschliche 
Fehler vermieden, da die Migration wesentlich systematischer 
20 erfolgt. 

In Figur 7 ist ein drittes Ausfuhrungsbei spiel in mehreren 
Untervarianten dargestellt, bei dem ebenfalls ein in XML— 
codierter Quellcode CodeML durch eine Transformation T in 
25 einen modif izierten CodeML* umgewandelt wird. Die 

Transformation T wird hier jedoch durch Transformationsregeln 
TR bewirkt, die in jeder Variante aus mindestens c und L 
bestehen und wie bei der Umsetzung von Templates TP 
zusatzlich mindestens ein Template-Fragment TPF enthalten, 
bspw. ftir die Umwandlung in eine EJB (Enterprise Java Bean) 
und bei der Umsetzung von Patterns P mindestens ein Pattern- 
Fragment PF besitzen, bspw. ftir die Anwendung von Proxy, 
Factory oder Singleton Patterns . Bei der Realisierung von 
Filtern FI gentigen C und L, da hier nur Code entfernt wird 
und so bspw. uberflttssige Output-Statements oder Kommentare 
beseitigt werden kSnnen. 



30 



35 
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Durch die entsprechende Anwendung von proxy patterns konnen 
local calls in remote calls oder in ahnlicher Weise local 
classes in EJB-classes (Enterprise Java Beans) umgewandelt 



werden. 



Umgekehrt kann mit Hilfe einer Transformation T und 
entsprechenden Regeln TR aus dem XML-codierten Quellcode 
JavaML oder einem Fragment dieses Codes auch ein giiltiges 
Template TP generiert werden, das als Vorlage ftir anderen 
Quellcode anwendbar ist. 

Die oben genannten Auspragungen des erf indungsgemafien 
Verfahrens konnen einzeln und in beliebiger Reihenfolge 
nacheinander erfolgen. 

Durch das erfindungsgemafie Verfahren ergeben sich noch eine 
Reihe von zusatzlichen Vorteilen, wie beispielsweise: 

1. Es kQnnen schnelle und flexible Anderungen im Quellcode 
vorgenommen werden. 

2. Es ist nur ein System far Problemstellungen wie 
Patternanwendung, Migration, AOP, Filtering, etc. 
erforderlich und nicht eine Reihe verschiedener teilweise 
proprietarer Werkzeuge. 

3. Das Verfahren basiert auf Standards wie XML und XSLT und 
ist hinsichtlich der Konvertierbarkeit in andere 
Programmiersprachen geringeren Beschrankungen unterworfen als 
andere Verfahren zur Modifikation von Quellcode. 

4. Selbst fur spezielle und komplizierte Quellcode- 
Modifikationen sind keine proprietaren Spezialldsungen 
erforderlich, sondern es kSnnen hierfUr existierende 
Standards wie XSLT, XPath und Xquery genutzt werden. 
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5. Diese Art der Modif ikation erlaubt die Erstellung von 
Hierarchien u.a. durch die Moglichkeit der 
Hintereinanderausftihrung (Pipelines) mehrerer 
Transf ormationen . 

i 

7. Die Transf ormationen konnen als allgemeine 
Transformationen ftir eine Wiederverwendung in XSLT-Dateien 
gespeichert werden, so dafi Bibliotheken z.B. far bestimmte 
Ablaufe entstehen konnen. 

8. Es kann eine XML-Reprasentation des Quellcodes in einer 
XML-Da tenbas is gespeichert und bei Bedarf mit Hilfe einer 
XSLT in einfacher Weise an die jeweiligen Kundenbedurfnisse 
angepasst werden. 

9. Durch die Verwendung der Standards XmlSchema oder DTD oder 

entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , 

auf bestimmte Korrektheitsaspekte hin, tiberprtift (validiert) 
werden . 

10. Ubliche XML-Visualisierungstools Tools konnen zur 
einfachen Bearbeitung bzw. Visual! sierung und Bestimmung von 
Beziehungen im Code verwendet werden. 

11. Dauerhafte XML-basierte Programmbibliotheken, die XPath- 
Anfragen untersttitzen, konnen die Wiederverwendung von Code 
durch besseres Auffinden eines Codes bzw. von Code- Fragment en 
oder Templates verbessert werden. 



4 . Erf indungsvariante 



35 



In Figur 8 ist ein Gesamtblockdiagramm zur Erlauterung der 
Erfindung dargestellt, bei dem zunachst ein Quellcode SC 
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durch einen Konverter CONV in einen in einer Meta- 
Auszeichnungssprache formulierten ersten Code CodeML 
umwandelt wird, wobei der Quellcode SC bei sofortiger 
Kompilierung einen Byte Code bzw. Binarcode B ergeben kann. 
Zu dem in der Meta-Auszeichnungssprache dargestellten Code 
CodeML wird nun eine zusatzliche Information INFO auf dem 
Wege einer durch Transformationsregeln TR beschriebenen 
Transformation T dem Code CodeML bzw. dem letztlich dem 
Quellcode SC hinzugefugt, wodurch sich ein zweiter ebenfalls 
in der Meta-Auszeichnungssprache formulierten Code CodeML* 
ergibt. Ein weiterer Konverter RCONV wandelt nach der 
Transformation den Code CodeML* in einen Quellcode SC* 
zuriick, der typischerweise in derselben Sprache wie der 
Quellcode SC formuliert ist. Durch einen Compiler COMP wird 
schlieBlich der modifizierte Code SC* in einen modif izierten 
Byte Code B* oder aber gleich in einen ausfuhrbaren Binarcode 
umgewandelt. Wesentlich ist hierbei, dass sich der Byte-Code 
B* vom Byte-Code B unterscheidet bzw. dass der Quellcode 
nicht nur in seiner Darstellung, sondern auch in seinem 
Programmablauf geandert wurde. 

Der Quellcode SC und der modifizierte Quellcode SC* sind 
beispielsweise in der Programmiersprache Java und die Codes 
CodeML und CodeML* sind beispielsweise in der Meta- 
Auszeichnungssprache XML formuliert, wobei „XML« fur Extended 
Markup Language steht. 

In Pigur 10 ist ein erstes Ausftihrungsbeispiel dargestellt, 
bei dem die zusatzliche Information INFO in Form von Daten'o, 
bspw. Initialisierungszustanden SSDb, Zustandsdaten SDa, 
Datenbankdaten Dc, beliebige Daten x, dem CodeML 
hinzugemischt werden, wobei diese Daten beispielsweise feste 
Zustande bzw. Werte fur Konstanten und Variablen darstellen. 
Auf diese Weise kann der Quellcode SC mit festen Zustanden 
versorgt und transformiert werden, so dass ein benetigter 
Zustand zur Laufzeit des Programiiis, z.B. als 

Initialisierungszustand SSDb, sofort zur Verftigung steht und 
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nicht mehr gesondert ermittelt werden muss. Auf diese Weise 
k6nnen auch Objekt-Zustande in den Code eingebracht werden, 
die ein Wiederauf setzen (Recovery) eines unterbrochenen 
Programms am selben Ort mit denselben Zustanden ermoglichen, 
5 ohne dass zusatzliche aufwandige programmtechnische 
Vorkehrungen hierftir getroffen werden mussen. 

Die Transformation T, z. B, eine Extended Stylesheet Language 
Transformation oder XSLT, wird durch Transformationsregeln 

10 TR, z. B . innerhalb von XSL (Extended Stylesheet Language) 
Dateien beschrieben, wobei bspw. die in XSL formulierten 
Regeln u.a. beschreiben wie der in XML-codierte Quellcode 
CodeML mit den Zustandsdaten aus D kombiniert wird, urn einen 
neuen modif izierten Quellcode CodeML* mit SSDb, SDa und Dc zu 

15 bilden. 

Die Regeln einer Transformation T konnen dabei so geartet 
sein, dass die Informationen in ihrer urspriinglichen Form 
aber auch in einer durch Regeln geanderten Form hinzugemischt 
20 werden. 

Die Regeln einer Transformation T kdnnen dabei auch so 

geartet sein, dass die Transformation T, z.B. mit Hilfe von 

if-conditions, durch die Informationen bzw. Daten beeinflusst 
25 werden. 

Die im Anhang 4 befindlichen Programmauf listungen Listing 1 
bis Listing 6 zeigen dies an einem konkreten Beispiel, bei 
dem in einer Testklasse des Quellcodes die nicht 
30 initialisierte Variable String m_sWelcome in eine 
initialisierte Form String m_sWelcome = "hello"; 
transformiert wird. Hierbei zeigt das Listing Idas 
entsprechende Java-Programm TestOutput . java, dass in eine 
XML-Darstellung TestOutput .xjava konvertiert wird. In Listing 
3 ist die XML-Datei State. XML mit dem Zustandswert "hello" 
dargestellt. In Listing 4 folgt dann die 

Transformationsanweisung zum Vermischen Mixing. xsl, die mit 
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Anweisungen wie template match « und apply- templates dafiir 
sorgen, dass der Code an der richtigen stelle modifiziert 
wird. 

■ 

In Pigur 9 ist ein zweites Ausfiihrungsbeispiel dargestellt, 
bei dem ein in XML codiertes Code-Fragment CFb mit einem 
ursprtinglichen in XML codierten Quellcode CodeML, der ein 
Code-Fragment CFa enthalt, durch die Transformation T derart 
transformiert wird, dass im modif izierten XML-codierten 
Quellcode CodeML* anstelle des bisher vorhandenen Fragments 
CFa ein Code-Fragment CFb enthalten ist. Die Transformation T 
wird hierbei auch von Trans format ionsregeln TR gesteuert. Ein 
derartiger Austausch von Code-Fragmenten kann unter 
bestimmten Umstanden z.B. als ^Patching* bezeichnet werden. 
Durch das erf indungsgemaiie Verfahren kann ein Patching in 
konsis tenter Weise mit einem maximalen Grad an Freiheit fur 
den Softwareentwickler erreicht werden, wobei dies 
beispielsweise automatisch und unter Berticksichtigung 
gegenseitiger Abhangigkeiten erfolgen kann. 

Fur dieses Ausfiihrungsbeispiel ist ein konkreter Fall durch 
die Listings 1A bis 6A der im Anhang 5 befindlichen 
Programmauflistungen gezeigt. Aus dem Java-Source-Code 
TestOutput. java wird wiederum ein TextOutput .xjava erzeugt. 
In Listing 3A kan man die Datei CodeFragment.xml erkennen, 
die ein Code-Fragment bereitstellt . Das Listing 4A enthalt 
nun in der Datei Patching.xsl die Regeln fur die 
Transformation T, wobei wiederum die Befehle template match = 
und apply-templates zum Einsatz kommen. Im Listing 5A ist 
dann der Inhalt der Datei TestOutput .xjava (*) mit dem 
modifizierten XML Quellcode und in Listing 6A in der Datei 
TestOutput. java (*) der modif izierte Java Quellcode 
dargestellt. Bei diesem Beispiel wird in der offentlichen 
Testklasse die Stringzuweisung String m_sWelcome = "hello"; 
durch eine Stringzuweisung String m_sWelcome = 
System . getProperty ( "WELCOME " ) ; ersetzt, wobei hier also der 
feste Wert "hello" durch die vom System angeforderte 
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Eigenschaft "WELCOME" ersetzt wird, und die beispielsweise 
irrttimlich „hardcodierte* Wertzuweisung nun „gepatched* 
werden kann. 

Figur 11 betrifft ein drittes Anwendungsbeispiel der 
Erfindung, bei dem die Informationen INFO von Zeichnung 1 
nicht nur in der oben angegebenen Weise in Form von 
Informationen INFOI, sondern auch zusatzlich Form von in den 
Transformationsregeln eingebetteten Informationen INF02 bzw. 
Fragmenten hinzugemischt werden. 

Figur 12 betrifft ein viertes Anwendungsbeispiel der 
Erfindung, bei dem XML-Quellcode CodeML mit dem Codefragment 
CF, das die Fremdsprachenfragmente LF1 und LF2 enthalt, durch 
die Transformation T kombiniert wird, urn einen modif izierten 
Code CodeML*, beispielsweise angepasst an die nattirliche 
Sprache des Benutzers (Ll=german) , zu erhalten. Die 
Transformation XSLT wird hierbei von Transformationsregeln TR 
bestimmt, die die zu andernden Stellen des Quellcodes sowie 
die jeweilige ausgewahlte nattirliche Sprache, also 
beispielsweise german oder english, spezif iziert . Durch das 
erfindungsgemafie Verfahren wird so eine Lokalisierung und 
Internationalisierung des Quellcodes auf effiziente und 
okonomische Weise, bei einer Minimierung der hierfiir 
erforderlichen zusatzlichen Laufzeit, erreicht. 

Die oben genannten Auspragungen des erf indungsgemaflen 
Verfahrens kSnnen einzeln und in beliebiger Reihenfolge 
nacheinander erfolgen. 

Durch das erfindungsgemaBe Verfahren ergeben sich eine Reihe 
von Vorteilen, wie beispielsweise: 



1. Es konnen schnelle und flexible Anderungen im Quellcode 
vorgenommen werden. 
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2. Es ist nur ein System far Problemstellungen wie Patching, 
Customizing, Updating, etc. erforderlich und nicht eine Reihe 
verschiedener teilweise proprietarer Werkzeuge. 

5 3. Das Verfahren basiert auf Standards wie XML und XSLT und 
ist hinsichtlich der Konvertierbarkeit in andere 
Programmiersprachen geringeren Beschrankungen unterworfen als 
andere Verfahren zur Modif ikation von Quellcode. 

10 4. Selbst fur spezielle und komplizierte Quellcode- 

Modifikationen sind keine proprietaren Speziallosungen 
erforderlich, sondern es kdnnen hierfur existierende 
Standards wie XSLT, XPath und XQuery genutzt werden. 

15 5. Diese Art der Modif ikation erlaubt die Erstellung von 
Hierarchien u.a. durch die Moglichkeit zur geordneten, 
automatisierten HintereinanderausfUhrung (Pipelines) mehrerer 
Transformationen, bspw. von Patches. 

7. Die Transformationen konnen fur eine allgemeine 
Wiederverwendung in XSLT-Dateien gespeichert werden, so dafi 
Bibliotheken z.B. fur bestimmte Ablaufe entstehen kSnnen. 

8. Es kann eine XML-Reprasentation des Quellcodes in einer 
25 XML-Datenbasis gespeichert und bei Bedarf mit Hilfe einer 

XSTL in einfacher Weise an die jeweiligen Kundenbedurfnisse 
angepasst werden (Customization) . 
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9. Durch die Verwendung der Standards XMLSchema oder DTD oder 

entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , 

auf bestimmte Korrektheitsaspekte hin, uberprttft (validiert) 
werden. 

10. Ubliche XML-Tools konnen zur einfachen Bearbeitung bzw. 
35 Visualisierung und Bestimmung von Beziehungen im Code 

verwendet werden. 
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11. Dauerhafte XML-basierte Programmbibliotheken, die XPath- 
Anfragen untersttitzen, konnen die Wiederverwendung von Code 
durch besseres Auffinden eines Codes bzw. von Code-Fragmente 
oder Templates verbessert werden. 
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Anhang 1 : 

Listing 1: TestRegistry. java 

5 

import electric. registry. Registry; 

public class TestRegistry 

{ 

10 //weiterer Quellcode in dem etwas geandert werden muss 

Listing 2: TestRegistry.xjava 

<?xtnl version="l. 0 n encoding= , *UTF-B ,, ?> 
15 < j ava> 

<import> 

<dot><dot><name>electric</name><name>registry</name></dot><name>Registry</name></dot> 
</ import > 

<class> 

2 0 <raodifiers><public/></modifiers> 
<name>TestRegistry</name> 
<block> 

<block> 
25 </class> 
</java> 



30 



Listing 3: VariationPointTl . xsl 

<xsl: stylesheet version="l . 0" xmlns:xsl«"http: //www.w3 .org/1 999/ XSL/ Trans form" > 
<l — ********************************* 



*** copy template ** 
****************** *************** > 

<xsl: template match-"* w > 
3 5 <xsl : copyXxsl : apply-templates/X/xsl : copy> 

</xsl : template> 

<l — ********************************************** 

*** Variotion Point Transformation 1 ** 
********************* ************************** > 

40 <xsl: template match= n import "> 

<xsl:if test= n dot/name= t Registry ,M > 
<import> 
<dot> 

ajz <dot><dot><dot><name>org</narae><name>apache</name></dot><name>axis</name></dot> 

<name>client</name></dot><name>Call</name> 
</dot> 

</import> 

<import> 

<dot> 

5 ^ <dot><dot><dot><name>org</name><name>apache</namex/dot><narae>axis</name></dot> 

<name>client</name></dot><name>Service</name> 
</dot> 

</import> 

</xsl:if> 

55 <xsl:if test="dot/name!= , Registry»"> 

<xsl:copy-of select=" . "/> 
</xsl:if> 

</xsl : template> 

60 </xsl:stylesheet> 
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4: TestRegistry.xjava (*) 

<?xml version= n 1.0" encoding= n UTF-8 n ?> 
<java> 

<import> 

<dot> 

<dot><dot><dot><name>org</name><name>apache</name></dot><name>axis</nam^^^ 
<name>client</name></dotXname>Call</name> axis</namex/dot> 
</dot> 
</import> 
<import> 
<dot> 

<name>client</name></dot><name>Service</name> v 
</dot> 

</import> 

<class> 

<modi f i ersxpublic/ X/modi f i ers> 

<name>TestRegi stry</name> 
<block> 

<block> 
</class> 
</java> 



Listing 5: TestRegfctry.java (*) 



import org. apache. axis. client. Call; //Axis 
import org . apache . axis . client . Service; 
public class TestRegistry 

... //weiterer Quellcode in dem etwas geandert wurde 
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Anhang 2 

Listing 1: TestOutputxjava 

<?xml version= n 1.0" encoding="UTF-8"?> 
<java> 

<define name="m" value=" private" > 
<class> 

<modifiers><m/x/modifiers> 

<name>TestOutput</name> 

<block> 

<var> 

<type><name>string</namex/type> 

<name>m_sWelconie</nanie> 
</var> 

</block> 

</class> 

</java> 



Listing 2: TestOutputxjava* 

<?xml version="1.0" encodings "UTF-8"?> 
< j ava> 

<class> 

<modifiers><private/x/modifiers> 

<name>TestOutput</name> 

<block> 

<var> 

<typexname>String</namex/type> 

<name>m_sWelcome</name> 
</var> 

</block> 

</class> 

</java> 

Listing 3: TestOutputjava 

private class TestOutput 
( 

String itt_sWelcome; 

} 
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Anhanq 3 

Listing 1: Test Calculator, java 

public class TestCalculator { 
private int z; 

public void calculate(int x f int y) { 
z = x+y; 

) 

) 



Listing 2: TestCalculatonxjava 



<?xml version«"1.0 n encoding=»"UTF-8 f, ''> 
<j ava> 

<class> 

<modifiers><public/X/modifiers> 

<name>TestCalculator</name> 
<block> 

<var> 

</vrr> lflerS><PriVate/></m0difierS><t ^ e><int/></t ^ e><name > z </"ame> 
<method> 

<modifiers><public/x/modifiers> 
<type><void/X/type> 

<name>calculate</name> 
<params> 

<param><type><int/X/typeXname>x</name></param> 

<paramxtypexint/x/typexnam e >y</namex/param> 
</params> 

<curly> 

<expr> 

<a> 

<name>z</name> 

</a> 1US ^ <name>X</name><name>y</name></plUS> 
</expr> 
</curly> 
</method> 
</block> 
</class> 
</java> 



Listing 3: LoggingAspectxsI 

<xsl : stylesheet veraion-1 . 0" xmlns ixal-https //www.w3. org/1999/XSL/Transform'«> 

<l — ********************************* 

*** copy template ** 
********************************* > 

<xsl: template match- r, *"> 

<xsl : copyxxsl : apply-templates/X/xsl : copy> 
</xsl : template> w 

<j — ********************************* 

*** logging aspect ** 
********************************* ^ 

<X ^s^Sy> 6 match -"* 1 <name( ) = • curly- ) and ( ancestor : : method [contains (name, 'cal')] ))'■> 

<expr> 
<paren> 

<exprs> 0t><name>SyStem</name><name>OUt</name></dot><nam ^ 
<expr> 
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<^xpr> eXt>W</XSl:teXt><XSl:ValUe *"° f selectsn -/n^V><xsl:text> begin«</x S l : text> 
</exprs> 
</paren> 
</expr> 

<xsl:copy-of select-"*" /> 
<expr> 
<paren> 

<expr^^ 
<expr> 

</expr> eXt> " </XSl:teXt><XSl:ValUe "° f select=M - •/nameVXxslrtext^ end»</x S l : text> 
</ exprs> 
</paren> 
</expr> 
</xsl ; copy> 
</xsl : template> 
</xsl : stylesheet> 

Listing 4: TestCaIculator*.xjava 

<?xml version«"1.0" encoding="UTF-8"?> 
< j ava> 
<class> 

<modifiersXpublic/X/modifiers> 

<name>TestCalculator</name> 

<block> 

<var> 

</va^f fierS><PriVate/></rtlfierS><t ^ e><int/X 
<method> 

<modifiers><public/x/modifiers> 
<type><vo±d/x/type> 

<name>calculate</name> 
<params> 

<param><typeXint/x/typeXname>x</name></param> 

<paramXtypeXint/X/type><name>y</nameX/param> 
</params> 

<curly> 

<e2spr> 

<paren> 

<dotXdotXname>System</nameXnaxne>out</nain^ 

<exprsXexpr>" calculate begin»</exprX/exprs> ' 
</paxen> 

</expr> 

<expr> 

<a> 

<name>z</ name> 

<plusXname>x</nameXname>y</nameX/plus> 
</a> 

</expr> 



<dotX^tXna mfi >System</nameXnaiue>oufc</naiiieX/dotXnaxne>print^n</n 
<exprsxexpr>» calculate end" </exprX/exprs> 7 

</paren> 

</expr> 

</curly> 

</method> 

</block> 

</class> 

</java> 



Listing 5: TestCalculator*.java 

public class TestCalculator{ 
private int z; 

public void calculate {int x, int y) { 
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System. out. println ("calculate begin") ; 
z = x+y; 

System. out. println ("calculate end") ; 

5 } 
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Anhang 4 



Listing 1: TestOutputjava 



public class TestOutput 
String mjsWelcome; 

} 



Listing 2: TestOutputxjava 



<?xml version= n 1.0" encoding="UTF-8"?> 
< j ava> 

<class> 

<modifiers><public/x/modifiers> 

<name>TestOutput</name> 

<block> 

<var> 

<typeXname>String</nameX/type> 
<name>m_sWelcome</name> 
</var> 

</block> 
</class> 
</java> 



Listing 3: State. xml 



<?xml version="1.0" encoding="UTF-8"?> 
<state name="ni_sWelcoitie"> 

<value>" hello" </value> 
</state> 



Listing 4: Mixing. xsl 

<xsl: stylesheet version="l . 0" 

xmlns:xsl="http://www.w3 .org/1999/XSL/Transform"> 
< i — ********************************* 

*** copy template ** 
*********************************__> 

<xsl: template match="*"> 

<xsl : copyxxsl : apply- templates/X/x si : copy> 
</xsl : template> 

<i — ********************************* 

*** mixing template ** 
*********************************__> 

<xsl: template match="* [ (name () = "var 1 ) and (name='m sWelcome » ) 1 "> 
<xsl:copy> ~* 

<xsl:copy-of select="*"/> 
<a> 

^<exprXxsl:value-of select=" //state [@name= 'm^sWelcome « ] /value" /></expr> 

</xsl : copy> 
</xsl : template> 
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</xsl : s tylesheet> 

Listing 5: TestOutput .xjava (*) 

5 <?xml version="1.0" encoding= f, UTF-8"?> 
<java> 

<class> 

<modifiers><public/X/modifiers> 
<name >T e s tOu tput </name> 
10 <block> 

<var> 

<type><name>string</name></type> 
<name>ia_sWelcome</name> 



15 



</var> 
</block> 
</class> 
20 </java> 



Listing 6: TestOutput . java (*) 

public class TestOutput 
25 { 

String m_sWe 1 corner" hello" ; 

) 
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Anhang 5 



Listing 1A: TestOutput java 

public class TestOutput 
{ 

String m_sWelcome=" hello" ; 

} 



Listing 2A: TestOutputxjava 

<?xml version= n 1.0" encoding="UTF-8"?> 
<java> 

<class> 

<modifiers><public/X/modifiers> 

<name>TestOutput</name> 

<block> 

<var> 

<type><name>string</namex/type> 

<name>m_sWelcome</name> 
<a> 

< expr > " hell o " < / expr > 
</a> 
</var> 
</block> 
</class> 
</java> 

Listing 3A: CodeFragznent . xml 



<?xml version=*"1.0" encodings "UTF-8"?> 
<fragment name="ia_sWelcome"> 
<expr> 
<paren> 

<dot><name>System</name><name>getProperty</name></dot> 
< expr s Xexpr> "WELCOME "</ expr X / expr s > 
</paren> 

</expr> 
</fragment> 



Listing 4A: Patching. xsl 

<xsl: stylesheet version="l . 0" 

xmlns :xsl="http://www.w3 - org/19 9 9/XSL/Trans form" > 

< j — ********************************* 

*** copy template ** 
**************** ***************** > 

<xsl:template match="*"> 

<xsl : copyxxsl : apply- templates/x/xsl : copy> 
</xsl : template> 

< t — ****************** *************** 

*** patching template ** 
************ ********************* > 

<xsl:template match="* [ (name () = 'a 1 ) and (ancestor : :var/name=» m_sWelcome 1 ) ] "> 
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<xsl : copy> 

</S^copyr° f select=V/fra P ent tenaine='m_sWelcome»]/expr n /> 

</xsl : template> 
</xsl : stylesheet> 

Listing 5A; TestOutput * xjava (*) 

<?xml version="1.0" encoding= ,r UTF-8 f, ?> 
< j ava> 

<class> 

<mocLLfiersXpublic/X/modifiers> 

<name>TestOutput</naine> 

<block> 

<var> 

<type><name>string</name></type> 

<name>m_sWelcome</naine> 
<a> 

<expr> 

<paren> 

<dot><name>System</naiae><nanie>getProperty</name></dot> 
<exprsXexpr>"WELCOME"</expr></exprs> 
</paren> 

</expr> 

</a> 

</var> 

</block> 

</class> 

</ j ava> 

Listing 6A: TestOutput . java (*) 

public class TestOutput 

String m_sWelcome=Sys tern . getProperty ( "WELCOME" ) ; 

} 
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15 



Patentansprtiche 

1. Verfahren zur Veranderung von Software, 

- bei dem vorab herstellerseitig aus einer nur aus Quelltext 
(SCI, SC2, SC) bestehenden ursprtinglichen Software eine 

Mischform der ursprtinglichen Software derart gebildet wird 
dass mindestens ein Teil (SCI) des Quelltexts in einen Byte- 
oder Binarcode (B1,..,B) compiliert und mindestens ein 
weiterer Teil (SC2) des Quelltexts in einen in einer Meta- 
Auszeichnungssprache formulierten Code (CodeML) ftir 
mindestens einen Variationspunkt (VP2, . .VP) konvertiert wird, 

- bei dem dann kundenseitig nach Bedarf nur mindestens ein 
Variationspunkt (VP2) der Mischform (SW) der ursprtinglichen 
Software durch eine Transformation (T) in Abhangigkeit von 
Transformationsregeln (TR) in mindestens einen in der Meta- 
Auszeichnungssprache formulierten anderen Code (CodeML*) 
umgewandelt wird und 

- bei dem der andere Code (CodeML*) direkt einen veranderten 
Variationspunkt (VP2* ) einer angepassten Software (SW*) 
bildet Oder aus dem anderen Code (CodeML*) durch einen 
Konverter (RCONV) ein Quellcode (SC*) und dann mittels eines 
Kompilers (COMP) ein Binar- oder ByteCode (B*) des 
veranderten Variationspunkts (VPB2) einer angepassten 
Software (SW*) gebildet wird, wobei sich die ursprtingliche 
(SW) und die angepasste Software (SW*) in ihrem 
Programmablauf bzw. Programminhalt unterscheiden. 

2. Verfahren nach Anspruch 1, 

30 bei dem die Transformationsregeln (TR) mindestens eine 
Modifikationsregel ftir einen Variationspunkt aufweisen. 

3. Verfahren nach Anspruch 1 oder 2, 

bei dem der Modifikationsregel ein Update auf eine neuere 
35 Softwareversion bzw. ein Patching anstdfit. 

4. Verfahren nach Anspruch 1 oder 2, 



20 



25 



34 



WO 2004/088549 



PCT7EP2004/003301 



bei dem die Modifikation mindestens eines Variationspunktes 
(VP) durch die Transformation zur Laufzeit erfolgt. 



5. Verfahren nach einem der vorhergehenden Ansprtiche, 
bei dem die Programmiersprache des Quellcodes Java und die 
Meta-Auszeichnungssprache der Variationspunkte XML ist und 
bei dem die Transformation und die Regelbeschreibung mittels 
XSLT und XSL erfolgt. 



6. Verfahren zur Veranderung von Quellcode, 

- bei dem ein in einer Meta-Auszeichnungsprache formulierter 
erster Code (CodeML) mit mindestens in einer Meta- 
Auszeichnungssprache formulierten Spracherweiterungen (LE) 
als Ausgangscode zur Verftlgung steht, 

- bei dem der Ausgangscode durch eine Transformation (T) in 
Abhangigkeit von Transf ormationsregeln (TR) in einen in der 
Meta-Auszeichnungssprache formulierter zweiten Code (CodeML*) 
ohne die in der Meta-Auszeichnungssprache formulierten 
Spracherweiterungen (LE) tiberfuhrt wird, 

- bei dem die Transf ormationsregeln einen Sprachkonverter 
(LC) bilden, der die Spracherweiterungen (LE) des ersten 
Codes so auflost bzw. anwendet, dass sie durch einen 
Riickkonverter (RCONV) der keine entsprechende 
Spracherweiterung aufweist verarbeitbar sind, und 

- bei dem dieser zweite Code in einen in der ersten 
Programmiersprache oder einer anderen Programmiersprache 
formulierten zweiten Quellcode (SC*) umwandelbar ist, und 
einen gUltigen Binarcode/ByteCode (B*) ergibt. 



7. Verfahren nach Anspruch 6, 
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bei dem im zweiten Code (CodeML*) mindestens eine 
Spracherweiterung (LE*) neu erzeugt oder aus dem ersten Code 
(CodeML) ubernommen wird, und diese Erzeugung oder Ubernahme 
der Sprachkonverter (LC) vornimrat. 

8. Verfahren zur Veranderung von Quellcode, 

- bei dem ein in einer ersten Programmiersprache formulierter 
Quellcode (SC) in einen in einer Meta-Auszeichnungssprache 
formulierten ersten Code (CodeML) umgewandelt wird, 

- bei dem eine Transformation (T) nur in Abhangigkeit von 
Transformationsregeln TR in einen in der Meta- 

zweiten Code (CodeML*) 

erfolgt und 

- bei dem dieser zweite Code in einen in der ersten 
Programmiersprache oder einer anderen Programmiersprache 
formulierten zweiten Quellcode (SC*) verwandelt wird, wobei 
sich der erste und der zweite Quellcode in ihrer 
Funktionalitat (B,B*) unterscheiden. 

9. Verfahren nach Anspruch 8, 

bei dem die Transformationsregeln (TR) mindestens eine 

Bedingung C und einen Logikbestandteil L und/oder 
Codefragment CF selbst enthalten. 

10. Verfahren nach Anspruch 8 oder 9, 

bei dem die Transformationsregeln (TR) mindestens ein 
Fragment in Form eines Templates (TPF) und/oder mindestens 
eines Patterns (PF) entalten, bei denen mit Hilfe der 
Transformation T mindestens eine Codeveranderung bewirkt. 

11. Verfahren nach Anspruch 10, 

bei dem TR derart ausgebildet ist, dass mit Hilfe der 
Trans format ionen T ein Mechanismus zur Sicherung mindestens 
eines Systemzustandes in den zweiten Quellcode (CodeML*) 
eingebracht wird, urn eine Migration in andere Versionen zu 
ermoglichen. 
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12. Verfahren nach Anspruch 8 oder 9, 

bei dem mit H-ilfe der Transformation T aus dem ersten Code 
oder einem Fragment des ersten Codes mindestens ein Template 
5 (TP) gebildet wird. 

13. Verfahren zur Veranderung von Quellcode, 

- bei dem ein in einer ersten Programmiersprache formulierter 
Quellcode (SC) in einen in einer Meta-Auszeichnungssprache 

10 formulierten ersten Code (CodeML) umgewandelt wird, 

- bei dem eine in der Meta-Auszeichnungssprache f ormulierte, 
den spateren Programmablauf (B*) beeinf lussende Information 
(INFO) durch eine Transformation (T) zu diesem ersten Code 
ersetzend oder nichtersetzend hinzugeftigt und so der 

15 ebenfalls in der Meta-Auszeichnungssprache formulierte 
zweiten Code (CodeML*) gebildet wird, wobei die 
Transformation in Abhangigkeit von in einer 

Transformationsbeschreibungssprache formulierten 
Transformationsregeln (TR) erfolgt, und 

- bei dem dieser zweite Code in einen in der ersten 
Programmiersprache oder einer anderen Programmiersprache 
formulierten zweiten Quellcode (SC*) verwandelt wird, wobei 
sich der Programminhalt bzw. Programmablauf (B) des ersten 
Quellcodes (SC) vom Programminhalt bzw. Programmablauf (B*) 

25 des zweiten Quellcodes (SC*) unterscheidet . 

14. Verfahren nach Anspruch 13, 

bei dem diese Information (INFO) mindestens ein Code-Fragment 
(CFb) enthalt und 

bei dem der zweite Quellcode dadurch gebildet wird, dass 
mindestens ein im ersten Quellcode enthaltenes Code-Fragment 
(CFa) mit Hilfe der Transformation durch das mindestens eine 
im Fragment enthaltene Code-Fragment (CFb) ersetzt wird. 

35 15. Verfahren nach Anspruch 13, 
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bei dem die Information (INFO) speziell Daten (D) in Form von 
Initialisierungszustanden (SSDb) oder Zustandsdaten (SDa) 
oder Datenbankdaten (Dc) enthalten. 

16. Verfahren nach Anspruch 15, 

bei die Transformationsregeln (TR) von diesen Daten (D) 
beeinflusst werden. 

17. Verfahren nach einem der Anspruche 13 bis 16, 

bei dem Daten (D) und/oder Code- Fragment e (CF) zusatzlich in 
den Transformationsregeln eingebettet sind. 

18. Verfahren nach einem der Anspruche 13 bis 17, 

bei dem von checkpoints generierte Daten mitt els einer 
Transformation so hinzugeftigt werden, das der interne Zustand 
des ursprtinglichen Programms beim Neustart des Programms zur 
Verftigung steht bzw. von diesem genutzt werden kann. 

19. Verfahren nach einem der Anspruche 13 bis 17, 

bei dem Informationen (INFO) Updates oder Patches enthalten. 

20. Verfahren nach Anspruch 13 bis 17, 

bei dem Fragmente (LF1, LF2) Informationen zur 
Internationalisierung enthalten, die der Anpassung an 
unterschiedliche natiirliche Sprachen dienen. 

21. Verfahren nach einem der Ansprtiche 13 bis 17, 

bei dem Daten und/oder Code-Fragmente aus einer Bibliothek 
entstammen und 

auf Kunden oder Kundengruppen abgestimmte Informationen 
tragen. 



22. Anordnung zur Veranderung von Software, 

- bei der eine Mischform einer ursprunglichen Software derart 
vorhanden ist, dass mindestens ein Teil (SCI) eines 
Quelltexts in einen Byte- oder Binarcode (B1,..,B) compiliert 
und mindestens ein weiterer Teil (SC2) des Quelltexts in 
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einen in einer Meta-Auszeichnungssprache formulierten Code 
(CodeML) ftlr mindestens einen Variationspunkt (VP2, . .VP) 
konvertiert ist, 

- bei der eine Einrichtung zur Transformation (T) derart 
5 vorhanden ist, dass nach Bedarf nur mindestens ein 

Variationspunkt (VP2) der Mischform (SW) der ursprtlnglichen 
Software 'durch die Transformation (T) in Abhangigkeit von 
Trans format ionsregeln (TR) in mindestens einen in der Meta- 
Auszeichnungssprache formulierten anderen Code (CodeML*) 
10 umwandelbar ist, 

wobei der andere Code. (CodeML*) direkt einen veranderten 
Variationspunkt (VP2* ) einer angepassten Software (SW*) 
bildet oder aus dem anderen Code (CodeML*) durch einen 
Konverter (RCONV) ein Quellcode (SC*) und dann mittels eines 
15 Compilers (COMP) ein Binar- oder ByteCode (B*) des 

veranderten Variationspunkts (VPB2) einer angepassten 
Software (SW* ) bildbar ist und wobei sich die ursprungliche 
(SW) und die angepasste Software (SW*) in ihrem 
Programmablauf bzw. Programminhalt unterscheiden. 
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23. Anordnung zur Veranderung von Quellcode, 

- bei der ein Prozessor derart vorhanden ist, dass eine 
Transformation (T) des Ausgangscodes (CodeML) in Abhangigkeit 

25 von in einer erweiterten Stilbeschreibungssprache 

formulierten Transf ormationsregeln (TR) und einen darin 
enthaltenen Sprachkonverter (LC) so durchgefuhrt wird, dass 
entweder ein in der Meta-Auszeichnungssprache formulierter 
zweiter Code (CodeML*) ohne die in der Meta- 

30 Auszeichnungssprache formulierten Spracherweiterungen (LE) 
des ersten Codes (CodeML) , 

oder ein in der Meta-Auszeichnungssprache formulierter 
zweiter Code (CodeML*) mit neuen und/oder den ursprunglichen 
in der Meta-Auszeichnungssprache formulierten 
35 Spracherweiterungen (LE) erzeugt wird, und 

- bei der ein Rtickkonverter (RCONV) derart vorhanden ist, 
dass dieser zweite Code in einen in der ersten 
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Programmiersprache oder einer anderen Programmiersprache 
formulierten Quellcode (SC*) verwandelt wird. 



24. Anordnung zur Veranderung von Quellcode, 

- bei der ein erster Konverter (CONV) derart vorhanden 1st, 
dass ein in einer ersten Programmiersprache formulierter 
Quellcode (SC) in einen in einer Meta-Auszeichnungssprache 
formulierten ersten Code (CodeML) umgewandelt wird, 

- bei der ein Prozessor derart vorhanden 1st, dass der CodeML 
durch eine Transformation (T) nur in Abhangigkeit von 
Transformationsregeln (TR) in einen in der Meta- 
Auszeichnungssprache formulierten zweiten Code (CodeML*) 
umgewandelt wird und 

- bei der ein zweiter Konverter (RCONV) derart vorhanden ist, 
dass dieser zweite Code in einen in der ersten 
Programmiersprache oder einer anderen Programmiersprache 
formulierten zweiten Quellcode (CodeML*) verwandelt wird, 
wobei sich der erste und der zweite Quellcode in ihrer 
Funktionalitat bzw. Inhalt(B,B*) unterscheiden. 



25. Anordnung zur Veranderung von Quellcode, 

- bei der ein erster Konverter (CONV) derart vorhanden ist, 
dass ein in einer ersten Programmiersprache formulierter 
Quellcode (SC) in einen in einer Meta-Auszeichnungssprache 
formulierten ersten Code (CodeML) umgewandelt wird, 

- bei der ein Prozessor derart vorhanden ist, dass eine in 
der Meta-Auszeichnungssprache formulierte, den spateren 
Programmablauf (B*) beeinf lussende Information (INFO) durch 
eine Transformation (T) zu diesem ersten Code ersetzend oder 
nichtersetzend hinzugeftlgt und so der ebenfalls in der Meta- 
Auszeichnungssprache formulierte zweiten Code (CodeML*) 
gebildet wird, wobei die Transformation in Abhangigkeit von 
in einer Trans formationsbeschreibungsspr ache formulierten 
Transformationsregeln (TR) erfolgt, und 
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- bei der ein zweiter Konverter (RCONV) derart vorhanden ist, 
dass dieser zweite Code in einen in der ersten 
Programmiersprache oder einer anderen Programmiersprache 
formulierten zweiten Quellcode (SC*) verwandelt wird, wobei 
5 sich der Programminhalt bzw. Programmablauf (B) des ersten 
Quellcodes (SC) vom Programminhalt bzw. Programmablauf (B*) 
des zweiten Quellcodes (SC*) unterscheidet . 
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